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Reply to Office Action of March 18, 2009 



REMARKS/ARGUMENTS 

This amendment and response is filed in reference to the non-final Office Action 
(hereinafter "Office Action") mailed March 18, 2009. In that Office Action, claims 1, 2, 9-10, 
12, 21-27, 30-33, and 42-50 were examined and all claims were rejected. Specifically, claims 1, 
2, 10, 12, 21-23, 26-27, and 30-32 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Achenson et al. (U.S. Patent No. 6,477,586; hereinafter "Achenson") in view of Link et al. 
(U.S. Patent No. 6,012,096; hereinafter "Link"). Applicants respectfully note that the patent 
number listed for Link in the Office Action was incorrect. Applicants have verified with 
Examiner Swearingen that the correct patent number for Link is U.S. Pat. No. 6,012,096. Claims 
9 and 33 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Achenson in view of 
Link and further in view of Bradley et al. (U.S. Patent No. 7,082,463; hereinafter "Bradley"). 
Claims 24 and 25 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Achenson 
in view of Link and further in view of Lowery et al. (U.S. Patent No. 7,454,457; hereinafter 
"Lowery"). Finally, claims 42-50 were rejected under 35 U.S.C. § 101 as allegedly drawn to 
non-statutory subject matter. 

Reconsideration of the objections and rejections, as they might apply to the original and 
amended claims in view of these remarks, is respectfully requested. In this Amendment, claims 
1, 12, 21, 23-25, 30-32, and 42-50 have been amended, claims 11, 22, 28-29, and 34-41 have 
been canceled, and claims 51-53 have been added. Therefore, claims 1-2, 9-10, 12, 21, 23-27, 
30-33, and 42-53 are present for examination. 

Applicants submit that amendments are supported throughout the specification, and in the 
claims as originally filed, and do not introduce new matter. For instance, support may be found 
in at least the following sections of the Specification: 

(1) Remote procedure calls (RPCs) are an example of a communications protocol. By 
utilizing remote procedure calls a program on one computer may execute a 
program on a server computer. A system developer may not need to develop 
specific procedures for the server: the client program sends a message to the 
server with appropriate arguments and the server returns a message containing the 
results of the program executed. (Specification, at 2, para. [0004].) 
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(2) In an embodiment of the invention, a client may be configured to refrain from 
sending the performance data alone. Instead, the client may store the performance 
data until, for example, a subsequent request/response cycle is initiated with the 
server. The client may incorporate the stored performance data into the 
subsequent request, thereby potentially reducing some of the overhead associated 
with sending the client-perceived performance data to the server. (Specification, 
at 21, para. [0054].) 

(3) The performance data 712 provides particular information from the client's 
perspective regarding the performance of the system, for example, 
request/response latency, request/response error codes and/or the frequency of 
error codes. (Specification, at 21-22, para. [0056].) 

(4) Examples of the server's performance data preferences include: whether and 
under what conditions the client 802 should send performance data, whether the 
client 802 should send performance data related to communications with servers 
other than the server 804 and if so what types of servers, and how long to store 
performance data before it becomes too old to be of interest. (Specification, at 24, 
para. [0061].) 

(5) In an embodiment of the invention, the messaging server 902, 904, or 906 returns 
a performance data enable flag to the messaging client 908 indicating whether or 
not the server 902, 904, or 906 wants to receive the client monitoring (i.e., 
performance) data. (Specification, at 27, para. [0068].) 

Claim Rejections - 35 U.S.C. § 101 

Claims 42-50 were rejected under 35 U.S.C. § 101 as allegedly drawn to non-statutory 
subject matter. Applicants respectfully traverse the rejection, but in the interest of furthering 
prosecution of the present application, claims 42-50 have been amended to recite: "A computer 
system, comprising: a processor, wherein the processor processes instructions for reporting 
performance data as perceived by a client in a client server network; and a computer storage 
medium having stored thereon the instructions for reporting performance data, the stored 
instructions comprising a data structure." As such, the data structure is processed by a tangible 
processor to yield a tangible result, i.e., "reporting performance data as perceived by a client in a 
client server network." In light of this amendment, Applicants respectfully request that 
Examiner withdraw the rejection and allow claims 42-50. 
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Claim Rejections - 35 U.S.C. $ 103 - Achenson and Link 

Claims 1, 2, 10, 12, 21-23, 26-27, and 30-32 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Achenson in view of Link. Applicants respectfully traverse the § 103(a) 
rejections because either the Examiner failed to state a prima facie case of obviousness or the 
current amendments to the claims now render the Examiner's arguments moot. To establish a 
prima facie case of obviousness under 35 U.S.C. § 103(a), the references must teach or suggest 
all of the claimed limitations to one of ordinary skill in the art at the time the invention was 
made. M.P.E.P §§ 2142, 2143.03; In re Royka, 490 F.2d 981, 985 (C.C.P.A. 1974); In re 
Wilson, 424 F.2d 1382, 1385 (C.C.P.A. 1970). Specifically, Achenson fails to teach or suggest 
all of the claimed limitations and Link fails to compensate for the deficiencies of Achenson. 

Achenson discloses a multi-threaded, multiple process distributed system including 
remote procedure call (RPC) messages. (Achenson, Abstract.) Specifically, Achenson discloses 
a plurality of processes, "each . . . comprising a plurality of threads and a means for receiving, 
composing, and forwarding remote procedure call messages." (Id., col. 2, 11. 17-19.) Achenson 
discloses a Process 1 which originates a RPC request message. (Id., col. 4, 11. 50-58.) The 
request message is then forwarded by intermediate processes until it reaches a Process N, which 
responds to the RPC message. (Id.) The response initiated by Process N is then forwarded 
through multiple processes back to Process 1, which initiated the RPC request. (Id., 11. 59-65.) 
Achenson' s distributed system may further be implemented using a TCP/IP protocol. (Id., col. 1, 
11. 34-36.) 

In contrast, the present application provides methods and systems for efficiently 
transmitting client-generated performance information to a server in one or more remote 
procedure calls (RPCs) between the client and the server. More specifically, as recited in claim 
1, the client first "detect[s] that a server is enabled to receive the performance information." The 
performance information "comprises at least one of: a request/response latency, a 
request/response error code, and a request/response error code frequency." The client also 
"dispatch[s] performance context information ... to the server, wherein the performance context 
information comprises one or more of: a client computer system host name, a client user name, a 
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client network adaptor name, a client network adaptor speed, and a client network protocol 
address." The client then "dispatch[es] a first request ... to the server, wherein the first request 
specifies a first remote procedure call (RPC)." The "first RPC comprises at least one argument 
for executing a program on the server." 

Claim 1 further recites that in response to the first request, the client "receiv[es] a first 
response from the server, wherein the first response corresponds to a result of the first RPC." 
The client then "measures] a time delay from the client's dispatch of the first request to the 
client's receipt of the first response from the server." The "time delay is a number of 
milliseconds between sending the first request and receiving the first response [and] ... is a 
request/response latency of the first request." The client "stor[es] the first request/response 
latency . . . until a second request specifying a second RPC is generated by the client" (emphasis 
added). The client then "append[s] the first request/response latency to a header of the second 
request from the client to the server [wherein] ... the second request specifies] the second RPC 
. . . different from the first RPC" (emphasis added). Unlike Achenson, the present methods 
utilize the header of an RPC transmitted by the client to the server to pass performance 
information. Thus, the present methods provide the advantages of "client side monitoring of 
client server communications" and the efficiency of passing the performance information by 
"appending it to at least one subsequent RPC." (Specification, at 4, para. [0009].) Additionally, 
there is no mention in Achenson of "detecting that a server is enabled to receive the 
performance information" and "dispatching performance context information from the client to 
the server." 

As such, Achenson fails to teach or disclose, inter alia, "detecting that a server is 
enabled to receive the performance information, wherein the performance information comprises 
at least one of: a request/response latency, a request/response error code, and a request/response 
error code frequency," "dispatching performance context information from the client to the 
server, wherein the performance context information comprises one or more of: a client 
computer system host name, a client user name, a client network adaptor name, a client network 
adaptor speed, and a client network protocol address," "in response to the received first response, 
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measuring a time delay from the client's dispatch of the first request to the client's receipt of the 
first response from the server . . . wherein the time delay is a request/response latency of the first 
request," "storing the first request/response latency at the client until a second request specifying 
a second RPC is generated by the client," and "appending the first request/response latency to a 
header of the second request from the client to the server . . . wherein the second request 
specifies the second RPC, and wherein the second RPC is different from the first RPC," as 
recited in claim 1 (emphasis added). 

Link fails to compensate for the deficiencies of Achenson. Link discloses a "method and 
system for determining network latency between clients in a computer network." (Link, 
Abstract.) More specifically, Link discloses an embodiment wherein "[o]ne client (e.g., the local 
client) sends an initial ping packet to another (e.g., a remote) client . . . [fjhe initial ping packet 
includ[ing] the local client's time stamp." (Id., 11. 17-20.) Thereafter, "[w]hen the remote client 
receives the initial packet ... the remote client (essentially immediately) responds with a 
response packet, wherein the response packet includes the remote client's current timestamp 
along with the other timestamp, which is left intact." (Id., 11. 20-25; emphasis added.) When the 
local client "receives the response at some later time ... the local client is able to determine the 
latency based on the new current (now later) time minus the earlier time saved in the local 
machine's timestamp." (Id., 11. 25-29.) The "local client also responds with a response-response 
packet to return the timestamp of the remote client to the remote client . . . [and the] remote 
client is then able to calculate the latency from its current time minus the time in its saved 
timestamp." (Id., 11. 29-33; emphasis added.) Finally, the local client "may also include the 
result of its latency calculation in the response-response packet, whereby the remote machine 
may average the two measured latencies for a better time estimate." (Id., 11. 34-37.) 

In contrast, the present claims recite "detecting that a server is enabled to receive the 
performance information" and "dispatching performance context information from the client to 
the server." The present claims also recite that performance information "comprises at least one 
of: a request/response latency, a request/response error code, and a request/response error code 
frequency" (emphasis added). Unlike Link, the present methods utilize the header of an RPC 
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transmitted by the client to the server to pass performance information. Thus, the present 
methods provide the advantages of "client side monitoring of client server communications" and 
the efficiency of passing the performance information by "appending it to at least one subsequent 
RPC." (Specification, at 4, para. [0009].) 

In sum, Link fails to disclose, inter alia, "detecting that a server is enabled to receive the 
performance information, wherein the performance information comprises at least one of: a 
request/response latency, a request/response error code, and a request/response error code 
frequency," "dispatching performance context information from the client to the server, wherein 
the performance context information comprises one or more of: a client computer system host 
name, a client user name, a client network adaptor name, a client network adaptor speed, and a 
client network protocol address," "dispatching a first request from the client to the server, 
wherein the first request specifies a first remote procedure call (RPC), and wherein the first RPC 
comprises at least one argument for executing a program on the server," "storing the first 
request/response latency at the client until a second request specifying a second RPC is 
generated by the client," and "appending the first request/response latency to a header of the 
second request from the client to the server . . . the second request specifying the second RPC . . . 
different from the first RPC," as recited in claim 1 (emphasis added). As such, claim 1 is 
allowable over the references of record. 

For at least the same reasons, independent claims 12, 30, and 32 are also allowable over 
the cited references. Independent claim 12 recites, inter alia, "detecting that a server is enabled 
to receive performance data, wherein the performance data comprises at least one of: a 
request/response latency, a request/response error code, and a request/response error code 
frequency," "sending performance context information from a client to the server, wherein the 
performance context information comprises one or more of: a client computer system host name, 
a client user name, a client network adaptor name, a client network adaptor speed, and a client 
network protocol address," "sending a first request from the client to the server, wherein the first 
request specifies a first remote procedure call (RPC), and wherein the first RPC comprises at 
least one argument for executing a program on the server," "calculating a first request/response 
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latency comprising a difference between the response received time for the first response and the 
request initiation time for the first request," "storing the first request/response latency at the 
client until a second request specifying a second RPC is generated by the client," and "sending a 
second request from the client to the server, the second request comprising: a header comprising 
the first request/response latency; and the second RPC, wherein the second RPC is different 
from the first RPC, and wherein the second RPC comprises at least one argument for executing a 
program on the server" (emphasis added). As such, Applicants respectfully request that the 
Examiner issue an allowance for claim 12, and its dependent claims 21, 23, and 26-27, at the 
Examiner's earliest convenience. 

Independent claim 30 recites, inter alia, "detecting that a first server is enabled to receive 
performance data, wherein the performance data comprises at least one of: a request/response 
latency, a request/response error code, and a request/response error code frequency," "sending 
performance context information from a client to the first server, wherein the performance 
context information comprises one or more of: a client computer system host name, a client user 
name, a client network adaptor name, a client network adaptor speed, and a client network 
protocol address," "calculating a request/response latency for the first request/response pair," 
"storing the request/response latency for the first request/response pair at the client until a second 
request specifying a second RPC is generated by the client," and "sending a second request from 
the client to a second server, the second request comprising: a header comprising the 
request/response latency for the first request/response pair; and the second RPC, wherein the 
second RPC is different from the first RPC" (emphasis added). As such, Applicants respectfully 
request that the Examiner issue an allowance for claim 30, and its dependent claim 31, at the 
Examiner's earliest convenience. 

Independent claim 32 recites, inter alia, "detecting that a server is enabled to receive 
performance data, wherein the performance data comprises at least one of: a request/response 
latency, a request/response error code, and a request/response error code frequency," 
"calculating a request/response latency for the first request/response pair comprising a 
difference between the response received time for the first response and the request initiation 
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time for the first request," "sending a second request from the client to the server, wherein the 
second request specifies the second RPC, and wherein the second RPC is different from the first 
RPC," and "when a difference between a request initiation time for the second request and the 
performance data storage time associated with the first request/response pair is less than a 
maximum performance data age threshold, incorporating the performance data associated with 
the first request/response pair into a header of the second request" (emphasis added). As such, 
Applicants respectfully request that the Examiner issue an allowance for claim 32 at the 
Examiner's earliest convenience. 

Claim Rejections - 35 U.S.C. S 103 - Achenson. Link and Bradley 

Claims 9 and 33 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Achenson in view of Link and further in view of Bradley. Applicants respectfully traverse the 
§ 103(a) rejections because either the Examiner failed to state a prima facie case of obviousness 
or the current amendments to the claims now render the Examiner's arguments moot. 
Specifically, Achenson fails to teach or suggest all of the claimed limitations and Link and 
Bradley fail to compensate for the deficiencies of Achenson. 

Bradley discloses a "Time-Based Service Monitoring mechanism for monitoring Service 
Level Agreements (SLAs) over specific time intervals." (Bradley, Abstract.) Bradley further 
discloses emailing results of the SLA monitoring to a customer. {Id., col. 9, 11. 19-20.) More 
specifically, Bradley discloses that "an SLA may guarantee that a customer will incure a 
maximum message latency of 200 milliseconds (ms) between devices A and B." (Id., col. 4, 11. 
28-30.) However, "a maximum message latency" is not equivalent to the "maximum 
performance data age threshold," as recited in claim 33 and in new claims 51-53. The Abstract 
notes that "performance data is stored on the client until transmitted or until it has aged beyond a 
server specified maximum age." The maximum performance data age threshold specifies the 
time that performance data should be stored. Beyond that period, the client will not send the data 
to the server. 
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Regarding claim 9, Bradley fails to make up for the deficiencies of Achenson and Link 
and claim 9 is allowable for at least the same reasons as claim 1. As such, Applicants 
respectfully request that the Examiner issue an allowance for claim 9 at the Examiner's earliest 
convenience. 

Regarding claim 33, Bradley fails to make up for the deficiencies of Achenson and Link 
and claim 9 is allowable for at least the same reasons as claim 32. As such, Applicants 
respectfully request that the Examiner issue an allowance for claim 33, as well as new claims 51- 
53, at the Examiner's earliest convenience. 

Claim Rejections - 35 U.S.C. § 103 - Achenson. Link and Lowery 

Claims 24 and 25 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Achenson in view of Link and further in view of Lowery. Applicants respectfully traverse the 
§ 103(a) rejections because either the Examiner failed to state a prima facie case of obviousness 
or the current amendments to the claims now render the Examiner's arguments moot. 
Specifically, Achenson fails to teach or suggest all of the claimed limitations and Link and 
Lowery fail to compensate for the deficiencies of Achenson. 

Lowery discloses methods and systems for receiving content from a data center. 
(Lowery, Abstract.) More specifically, Lowery discloses that a GUID may be inserted into the 
request for content. (Id., cols. 17:7-32; 18:40-60.) However, Lowery fails to make up for the 
deficiencies of Achenson and Link, and claims 24 and 25 are allowable for at least the same 
reasons as claim 12 from which they depend. As such, Applicants respectfully request that the 
Examiner issue an allowance for claims 24 and 25 at the Examiner's earliest convenience. 
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CONCLUSION 



This Amendment fully responds to the Office Action mailed on March 18, 2009. Still, 
that Office Action may contain arguments and rejections that are not directly addressed by this 
Amendment due to the fact that they were rendered moot in light of the preceding arguments in 
favor of patentability. Hence, the failure of this Amendment to directly address an argument 
raised in the Office Action should not be taken as an indication that the Applicants believe the 
argument has merit. Furthermore, the claims of the present application may contain other 
elements, not discussed in this Amendment, which are not shown, taught, or otherwise suggested 
by the art of record. Accordingly, the preceding arguments in favor of patentability are advanced 
without prejudice to other bases of patentability. 

It is believed that no further fees are due with this Response. However, the 
Commissioner is hereby authorized to charge any deficiencies or credit any overpayment with 
respect to this patent application to deposit account number 13-2725. 

In light of the above remarks and amendments, it is believed that claims 1-2, 9-10, 12, 21, 
23-27, 30-33, and 42-53 are now in condition for allowance, and Applicant respectfully requests 
a Notice of Allowance. If the Examiner believes a telephone conference would advance the 
prosecution of this application, the Examiner is invited to telephone the undersigned at the 
below-listed telephone number. 



Respectfully submitted, 



PATENT TRADEMARK OFFICE 



27488 




MERCHANT & GOULD P.C. 
P.O. Box 2903 

Minneapolis, Minnesota 55402-0903 
(303)32#S43 



Date: June 18,2009 
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